`:top
In `F33f`_`[object-oriented programming`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Object-oriented_programming]`_`f such as is often used in `F33f`_`[C++`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=C++]`_`f and `F33f`_`[Object Pascal`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Object_Pascal]`_`f, a `!virtual function`! or `!virtual method`! is an inheritable and `F33f`_`[overridable`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Method_overriding_(programming)]`_`f `F33f`_`[function`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Function_(computer_science)]`_`f or `F33f`_`[method`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Method_(computer_science)]`_`f that is `F33f`_`[dispatched dynamically`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Dynamic_dispatch]`_`f. Virtual functions are an important part of (runtime) `F33f`_`[polymorphism`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Polymorphism_(computer_science)]`_`f in `F33f`_`[object-oriented programming`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Object-oriented_programming]`_`f (OOP). They allow for the execution of target functions that were not precisely identified at compile time.
Most programming languages, such as `F33f`_`[JavaScript`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=JavaScript]`_`f and `F33f`_`[Python`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Python_(programming_language)]`_`f, treat all methods as virtual by default`:cite-ref-1[`F5bf`_`[1`#cite-note-1]`_`f]`:cite-ref-2[`F5bf`_`[2`#cite-note-2]`_`f] and do not provide a modifier to change this behavior. However, some languages provide modifiers to prevent methods from being overridden by derived classes (such as the `*final`* and `*private`* keywords in `F33f`_`[Java`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Java_(programming_language)]`_`f`:cite-ref-3[`F5bf`_`[3`#cite-note-3]`_`f] and `F33f`_`[PHP`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=PHP]`_`f`:cite-ref-4[`F5bf`_`[4`#cite-note-4]`_`f]).
>>Contents
• `F0af`_`[Purpose`#purpose]`_`f
• `F0af`_`[Example`#example]`_`f
• `F0af`_`[C++`#c]`_`f
• `F0af`_`[C`#c]`_`f
• `F0af`_`[Abstract classes and pure virtual functions`#abstract-classes-and-pure-virtual-functions]`_`f
• `F0af`_`[Behavior during construction and destruction`#behavior-during-construction-and-destruction]`_`f
• `F0af`_`[Virtual destructors`#virtual-destructors]`_`f
• `F0af`_`[See also`#see-also]`_`f
• `F0af`_`[References`#references]`_`f
-─
>>Purpose
The concept of the virtual function solves the following problem:
In `F33f`_`[object-oriented programming`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Object-oriented_programming]`_`f, when a derived class inherits from a base class, an object of the derived class may be referred to via a `F33f`_`[pointer`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Pointer_(computer_programming)]`_`f or `F33f`_`[reference`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Reference_(computer_science)]`_`f of the base class type instead of the derived class type. If there are base class methods overridden by the derived class, the method actually called by such a reference or pointer can be bound (linked) either "early" (by the compiler), according to the declared type of the pointer or reference, or "late" (i.e., by the runtime system of the language), according to the actual type of the object referred to.
Virtual functions are resolved "late". If the function in question is "virtual" in the base class, the most-derived class's implementation of the function is called according to the actual type of the object referred to, regardless of the declared type of the pointer or reference. If it is not "virtual", the method is resolved "early" and selected according to the declared type of the pointer or reference.
Virtual functions allow a program to call methods that don't necessarily even exist at the moment the code is compiled.
In C++, `*virtual methods`* are declared by prepending the `B100`F9d9virtual`f`b keyword to the function's declaration in the base class. This modifier is inherited by all implementations of that method in derived classes, meaning that they can continue to over-ride each other and be late-bound. And even if methods owned by the base class call the virtual method, they will instead be calling the derived method. `*Overloading`* occurs when two or more methods in one class have the same method name but different parameters. `*Overriding`* means having two methods with the same method name and parameters. Overloading is also referred to as function matching, and overriding as dynamic function mapping.
>>Example
>>>C++
For example, a base class `B100`F9d9Animal`f`b could have a virtual function `B100`F9d9eat`f`b. Subclass `B100`F9d9Llama`f`b would implement `B100`F9d9eat`f`b differently than subclass `B100`F9d9Wolf`f`b, but one can invoke `B100`F9d9eat`f`b on any class instance referred to as Animal, and get the `B100`F9d9eat`f`b behavior of the specific subclass.
`B100`F9d9import std;`f`b
`B100`F9d9`f`b
`B100`F9d9class Animal {`f`b
`B100`F9d9public:`f`b
`B100`F9d9 // Intentionally not virtual:`f`b
`B100`F9d9 void move() {`f`b
`B100`F9d9 std::println("This animal moves in some way");`f`b
`B100`F9d9 }`f`b
`B100`F9d9`f`b
`B100`F9d9 virtual void eat() = 0;`f`b
`B100`F9d9};`f`b
`B100`F9d9`f`b
`B100`F9d9// The class "Animal" may possess a definition for Eat if desired.`f`b
`B100`F9d9class Llama : public Animal {`f`b
`B100`F9d9public:`f`b
`B100`F9d9 // The non virtual function Move is inherited but not overridden.`f`b
`B100`F9d9 void eat() override {`f`b
`B100`F9d9 std::println("Llamas eat grass!");`f`b
`B100`F9d9 }`f`b
`B100`F9d9};`f`b
This allows a programmer to process a list of objects of class `B100`F9d9Animal`f`b, telling each in turn to eat (by calling `B100`F9d9eat`f`b), without needing to know what kind of animal may be in the list, how each animal eats, or what the complete set of possible animal types might be.
>>>C
In C, the mechanism behind virtual functions could be provided in the following manner:
`B100`F9d9#include <stdio.h>`f`b
`B100`F9d9`f`b
`B100`F9d9/* an object points to its class... */`f`b
`B100`F9d9typedef struct {`f`b
`B100`F9d9 const AnimalVTable* vtable;`f`b
`B100`F9d9} Animal;`f`b
`B100`F9d9`f`b
`B100`F9d9/* which contains the virtual function Animal.eat */`f`b
`B100`F9d9typedef struct {`f`b
`B100`F9d9 void (*eat)(Animal* self); // 'virtual' function`f`b
`B100`F9d9} AnimalVTable;`f`b
`B100`F9d9`f`b
`B100`F9d9/*`f`b
`B100`F9d9 Since Animal.move is not a virtual function`f`b
`B100`F9d9 it is not in the structure above.`f`b
`B100`F9d9*/`f`b
`B100`F9d9void move(const Animal* self) {`f`b
`B100`F9d9 printf("<Animal at %p> moved in some way\\n", (void*)(self));`f`b
`B100`F9d9}`f`b
`B100`F9d9`f`b
`B100`F9d9/*`f`b
`B100`F9d9 unlike move, which executes Animal.move directly,`f`b
`B100`F9d9 Eat cannot know which function (if any) to call at compile time.`f`b
`B100`F9d9 Animal.eat can only be resolved at run time when eat is called.`f`b
`B100`F9d9*/`f`b
`B100`F9d9void eat(Animal* self) {`f`b
`B100`F9d9 const AnimalVTable* vtable = self->vtable;`f`b
`B100`F9d9 if (vtable->eat != NULL) {`f`b
`B100`F9d9 (*vtable->eat)(self); // execute Animal.eat`f`b
`B100`F9d9 } else {`f`b
`B100`F9d9 fprintf(stderr, "'eat' virtual method not implemented\\n");`f`b
`B100`F9d9 }`f`b
`B100`F9d9}`f`b
`B100`F9d9`f`b
`B100`F9d9/*`f`b
`B100`F9d9 implementation of Llama.eat this is the target function`f`b
`B100`F9d9 to be called by 'void eat(Animal* self).'`f`b
`B100`F9d9*/`f`b
`B100`F9d9static void _Llama_eat(Animal* self) {`f`b
`B100`F9d9 printf("<Llama at %p> Llamas eat grass!\\n", ( void* )(self));`f`b
`B100`F9d9}`f`b
`B100`F9d9`f`b
`B100`F9d9/* initialize class */`f`b
`B100`F9d9const AnimalVTable Animal = { NULL }; // base class does not implement Animal.Eat`f`b
`B100`F9d9const AnimalVTable Llama = { _Llama_eat }; // but the derived class does`f`b
`B100`F9d9`f`b
`B100`F9d9int main(void) {`f`b
`B100`F9d9 /* init objects as instance of its class */`f`b
`B100`F9d9 struct Animal animal = { &Animal };`f`b
`B100`F9d9 struct Animal llama = { &Llama };`f`b
`B100`F9d9 move(&animal); // Animal.move`f`b
`B100`F9d9 move(&llama); // Llama.move`f`b
`B100`F9d9 eat(&animal); // cannot resolve Animal.eat so print "Not Implemented" to stderr`f`b
`B100`F9d9 eat(&llama); // resolves Llama.eat and executes`f`b
`B100`F9d9}`f`b
>>Abstract classes and pure virtual functions
A `!pure virtual function`! or `!pure virtual method`! is a virtual function that is required to be implemented by a derived class if the derived class is not `F33f`_`[abstract`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Abstract_type]`_`f. Classes containing pure virtual methods are termed "abstract" and they cannot be instantiated directly. A `F33f`_`[subclass`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Subclass_(computer_science)]`_`f of an `F33f`_`[abstract class`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Abstract_class]`_`f can only be instantiated directly if all inherited pure virtual methods have been implemented by that class or a parent class. Pure virtual methods typically have a declaration (`F33f`_`[signature`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Type_signature]`_`f) and no definition (`F33f`_`[implementation`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Method_implementation]`_`f).
As an example, an abstract base class `B100`F9d9MathSymbol`f`b may provide a pure virtual function `B100`F9d9doOperation()`f`b, and derived classes `B100`F9d9Plus`f`b and `B100`F9d9Minus`f`b implement `B100`F9d9doOperation()`f`b to provide concrete implementations. Implementing `B100`F9d9doOperation()`f`b would not make sense in the `B100`F9d9MathSymbol`f`b class, as `B100`F9d9MathSymbol`f`b is an abstract concept whose behaviour is defined solely for each given kind (subclass) of `B100`F9d9MathSymbol`f`b. Similarly, a given subclass of `B100`F9d9MathSymbol`f`b would not be complete without an implementation of `B100`F9d9doOperation()`f`b.
Although pure virtual methods typically have no implementation in the class that declares them, pure virtual methods in some languages (e.g. C++ and Python) are permitted to contain an implementation in their declaring class, providing fallback or default behaviour that a derived class can delegate to, if appropriate.`:cite-ref-5[`F5bf`_`[5`#cite-note-5]`_`f]`:cite-ref-6[`F5bf`_`[6`#cite-note-6]`_`f]
Pure virtual functions can also be used where the method declarations are being used to define an `F33f`_`[interface`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Interface_(Java)]`_`f – similar to what the interface keyword in Java explicitly specifies. In such a use, derived classes will supply all implementations. In such a `F33f`_`[design pattern`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Design_pattern]`_`f, the abstract class which serves as an interface will contain `*only`* pure virtual functions, but no data members or ordinary methods. In C++, using such purely abstract classes as interfaces works because C++ supports `F33f`_`[multiple inheritance`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Multiple_inheritance]`_`f. However, because many OOP languages do not support multiple inheritance, they often provide a separate interface mechanism. An example is the `F33f`_`[Java programming language`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Java_(programming_language)]`_`f.
>>Behavior during construction and destruction
Languages differ in their behavior while the `F33f`_`[constructor`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Constructor_(computer_science)]`_`f or `F33f`_`[destructor`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Destructor_(computer_science)]`_`f of an object is running. For this reason, calling virtual functions in constructors is generally discouraged.
In C++, the "base" function is called. Specifically, the most derived function that is not more derived than the current constructor or destructor's class is called.`:cite-ref-cpp-std-7-0[`F5bf`_`[7`#cite-note-cpp-std-7]`_`f]`:cite-ref-chen-8-0[`F5bf`_`[8`#cite-note-chen-8]`_`f]`:cite-ref-9[`F5bf`_`[9`#cite-note-9]`_`f] If that function is a pure virtual function, then `F33f`_`[undefined behavior`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Undefined_behavior]`_`f occurs.`:cite-ref-cpp-std-7-1[`F5bf`_`[7`#cite-note-cpp-std-7]`_`f]`:cite-ref-chen-8-1[`F5bf`_`[8`#cite-note-chen-8]`_`f] This is true even if the class contains an implementation for that pure virtual function, since a call to a pure virtual function must be explicitly qualified.`:cite-ref-10[`F5bf`_`[10`#cite-note-10]`_`f] A conforming C++ implementation is not required (and generally not able) to detect indirect calls to pure virtual functions at `F33f`_`[compile time`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Compile_time]`_`f or `F33f`_`[link time`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Link_time]`_`f. Some `F33f`_`[runtime systems`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Runtime_system]`_`f will issue a pure virtual function call error when encountering a call to a pure virtual function at `F33f`_`[run time`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Runtime_(program_lifecycle_phase)]`_`f.
In Java and C#, the derived implementation is called, but some fields are not yet initialized by the derived constructor (although they are initialized to their default zero values).`:cite-ref-11[`F5bf`_`[11`#cite-note-11]`_`f] Some `F33f`_`[design patterns`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Design_pattern_(computer_science)]`_`f, such as the `F33f`_`[Abstract Factory Pattern`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Abstract_Factory_Pattern]`_`f, actively promote this usage in languages supporting this ability.
>>Virtual destructors
Object-oriented languages typically manage memory allocation and de-allocation automatically when objects are created and destroyed. However, some object-oriented languages allow a custom `F33f`_`[destructor`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Destructor_(computer_programming)]`_`f method to be implemented, if desired. If the language in question uses automatic memory management, the custom destructor (generally called a finalizer in this context) that is called is certain to be the appropriate one for the object in question. For example, if an object of type Wolf that inherits Animal is created, and both have custom destructors, the one called will be the one declared in Wolf.
In manual memory management contexts, the situation can be more complex, particularly in relation to `F33f`_`[static dispatch`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Static_dispatch]`_`f. If an object of type Wolf is created but pointed to by an Animal pointer, and it is this Animal pointer type that is deleted, the destructor called may actually be the one defined for Animal and not the one for Wolf, unless the destructor is virtual. This is particularly the case with C++, where the behavior is a common source of programming errors if destructors are not virtual.
>>See also
• `F33f`_`[Abstract method`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Abstract_method]`_`f
• `F33f`_`[Inheritance (object-oriented programming)`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Inheritance_(object-oriented_programming)]`_`f
• `F33f`_`[Superclass (computer science)`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Superclass_(computer_science)]`_`f
• `F33f`_`[Virtual inheritance`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Virtual_inheritance]`_`f
• `F33f`_`[Virtual class`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Virtual_class]`_`f
• `F33f`_`[Interface (object oriented programming)`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Interface_(object_oriented_programming)]`_`f
• `F33f`_`[Component object model`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Component_Object_Model]`_`f (Microsoft's COM)
• `F33f`_`[Virtual method table`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Virtual_method_table]`_`f
>>References
`:cite-note-1`!1.`! `F0af`_`[↑`#cite-ref-1]`_`f "Polymorphism (The Java™ Tutorials > Learning the Java Language > Interfaces and Inheritance)". `*docs.oracle.com`*. Retrieved 2020-07-11.
`:cite-note-2`!2.`! `F0af`_`[↑`#cite-ref-2]`_`f "9. Classes — Python 3.15.5 documentation". `*docs.python.org`*. Retrieved 2025-07-05.
`:cite-note-3`!3.`! `F0af`_`[↑`#cite-ref-3]`_`f "Writing Final Classes and Methods (The Java™ Tutorials > Learning the Java Language > Interfaces and Inheritance)". `*docs.oracle.com`*. Retrieved 2020-07-11.
`:cite-note-4`!4.`! `F0af`_`[↑`#cite-ref-4]`_`f "PHP: Final Keyword - Manual". `*www.php.net`*. Retrieved 2020-07-11.
`:cite-note-5`!5.`! `F0af`_`[↑`#cite-ref-5]`_`f Pure virtual destructors - cppreference.com
`:cite-note-6`!6.`! `F0af`_`[↑`#cite-ref-6]`_`f "abc — Abstract Base Classes: @abc.abstractmethod"
`:cite-note-cpp-std-7`!7.`! `F0af`_`[↑`#cite-ref-cpp-std-7-0]`_`f "N4659: Working Draft, Standard for Programming Language C++" (PDF).
`:cite-note-chen-8`!8.`! `F0af`_`[↑`#cite-ref-chen-8-0]`_`f `:citerefchen2004`a`F33f`_`[Chen, Raymond`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Raymond_Chen]`_`f (April 28, 2004). "What is __purecall?".
`:cite-note-9`!9.`! `F0af`_`[↑`#cite-ref-9]`_`f `:citerefmeyers2005`a`F33f`_`[Meyers, Scott`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Scott_Meyers]`_`f (June 6, 2005). "Never Call Virtual Functions during Construction or Destruction".
`:cite-note-10`!10.`! `F0af`_`[↑`#cite-ref-10]`_`f `:citerefchen2013`a`F33f`_`[Chen, Raymond`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Raymond_Chen]`_`f (October 11, 2013). "C++ corner case: You can implement pure virtual functions in the base class".
`:cite-note-11`!11.`! `F0af`_`[↑`#cite-ref-11]`_`f `:citerefganesh2011`aGanesh, S.G. (August 1, 2011). "Joy of Programming: Calling Virtual Functions from Constructors".
`c`F0af`_`[↑ Back to top`#top]`_`f`a